Q&A
回答有難うございます。
「繰り返す」というのがポイントなのですね。
是非実践させていただこうと思います。
私は知識なし、技術なし、経験なしから2年前にプログラマに転職しました。
ガッツリ、プログラムを触る業務に携わりだしたのは1年弱くらい前になります。
社内研修でJavaやVBの基礎知識を学んだりはしていたので、入門書によくある基礎的な「決まり事」のようなことは分かるのですが、実装してみろと言われた時に、ロジックを考えるのに時間がかかる、もしくは考えきる事もできず先輩に引き取っていただくほかなくなる、というようなことがよくあり、申し訳無さと悔しさでいっぱいです。
年数だけはどんどん経ってしまうので、「1年やってこの実力は厳しい」などと言われてしまうことも増えてきました。
ロジックが組めないと言っても、おおまかな処理を日本語で書くことはできます。
ただ、その中の細かい処理のロジックがわからなくなってしまうのです。
例えば、
・新旧のエクセルファイルの内容を比較する
・旧ファイルの内容が「●▲■」の時新ファイルの内容も同じかつ同件数なら「正」
・旧ファイルの内容が「● ■」の時（●▲■のうち一つでも欠けている時）不正データとして「誤」
・旧ファイルの内容が「●▲■」のデータ件数と新ファイルの内容が同じデータ件数が不一致なら「誤」
など、このような処理をする時に、それを実現するための細かい手順が頭の中がごちゃごちゃになって分からなくなってしまいます。
先輩方に相談しても「慣れだよ慣れ」や「経験しかない」などの返答しかいただけないので、一体どのような対策をすればいいか分かりません。
ロジックを時間をかけず考えられるようになるにはどのような訓練をしたらいいのでしょうか。または、これを読んでおくと役に立つ、というような書籍等ありますでしょうか。
アドバイスや紹介等いただけたら嬉しいです。
よろしくお願い致します。
補足）関係あるかは分かりませんが、私は完全なる文系脳です。プログラムというものを掴み出すのも後輩より遅く、上司には勘が悪いと評価されています。
追記：
重要ではないと思いますがJavaは勉強はしていても業務で使用したことが一度もありません。
お恥ずかしながら最近やっとクラス間の値の流れや返り値の扱いなどがある日なんとなくピンと来ました。先月上旬まで人のコードが上手く読めない状態でした。
また、ロジックを自分で一から考えるべき機会はほぼVBAが多く、上記例もVBAでのものです。ロジックの考え方云々には言語は関係ないと思いますが。。。
今回もVBAでのExcelファイルのマッチング処理の実装で以下の①～⑤の手順でやってみて、と言われてその通りにしました。
①仕様や参考資料を見る
②大まかな処理すべきことを以下の例のように日本語で箇条書きに書く
例
１．マクロファイル起動後フォームを表示
２．参照ボタン押下時にファイル選択ダイアログを表示
３．処理開始ボタン押下時に必要な処理は以下の通り（順序不同）
①ファイル選択がされていない時はエラー
②旧データの特定のキー№がすべて入力されているかチェック
③同じキー№の組合せデータの件数をチェック
④同じキー№の組合せのデータを新データにあるかチェック
⑤新データに一致データがある場合は件数をチェック
⑥新旧で件数に差異がある場合は該当データを全てBシートに出力
⑦キー№の入力値、同一組合せデータの件数が新旧一致していたら該当データをすべてAシートに出力
⑧旧データの特定のキー№がどれか一つでも未入力の場合該当データを全てBシートに出力
４．閉じるボタン押下時はフォームを閉じる
③テストケースを考える（テスト仕様書作成）
④テストデータ作成
⑤テスト実施
上記日本語処理も先輩に確認して頂いてGoサインが出てからPGに入りましたが、一致キー№を１：１の場合なら実装できても、件数に関する点やデータの内容によって出力シートを分ける点に関する具体的実装がどこからどうすればいいかわからなくなってしまいました。
回答11件
0
ひとつの提案としては、IPAの基本情報技術者試験を受けると良いかもしれません。資格がどうこうではなく、そのための勉強がプログラマやSEへの基礎を一通り網羅する構成になっているからです。私も文系なので最初はそこから入りました。
https://www.ipa.go.jp/
擬似言語によるアルゴリズムなどは先輩から言わせると「現場では役に立たない」などと言われることもありますが、基礎の基礎だから当然であって、それも知らないとお話にならないという土台の部分です。
投稿2015/08/11 23:39
退会済みユーザー
総合スコア0
0
昔、新人研修で教えていた訓練法を記載します。
1)大まかにやりたいことを文字にする。(ここまではできているみたいですね。)
2)1の内容をソースコード中にコメントとして先に記入する。
3)2の内容をコーディング
4)3で自身のコメントで不十分だと思ったことをコメントとして記入する。
上を繰り返すことで、最終的にはコメント付きのコードが出来上がります。
この方法を取ることで次のことができます。
利点1)自分の考えとソースコードが並んでいるので見直しに使える。
利点2)先輩等に確認するとき、コメント部分を見てもらうことで考えたことを説明することができる。
投稿2015/08/12 13:24
総合スコア18155
0
細かいロジックを考えるとグチャグチャになるとのことですが、
いっぺんに細かく考えようとしていませんか？
(そうでなければ以下的外れになるので流して下さい)
例示の
・新旧のエクセルファイルの内容を比較する
を考えます。
こういう時は細かいロジックを考えずに、
都合のいいメソッドがあるものとして一旦コードを組んでしまいます。
・旧ファイルの内容が「●▲■」の時新ファイルの内容も同じかつ同件数なら「正」
・旧ファイルの内容が「● ■」の時（●▲■のうち一つでも欠けている時）不正データとして「誤」
・旧ファイルの内容が「●▲■」のデータ件数と新ファイルの内容が同じデータ件数が不一致なら「誤」
これをそのままコードにします。
bool ファイル比較(){ if(必要データ欠けてる()) return false; if(件数足りない()) return false; return true; }
人間の記憶力と向けられる関心には限りがあるので、
必ずコードを実際に書いて残しておきます。
で、次に「必要データ欠けてる()」と「件数足りない()」を作ります。
これらも都合のいいメソッドが存在するとして組みます。
こういったことを「都合のいいメソッド」が「存在するメソッド」になるまで繰り返します
大事なのは、例えば「必要データ欠けてる()」を考えるときは、
他のロジックのことは一切考えないことです。
考えると訳が解からなくなります。
何に使うために考えているかは書いて残したコードを辿れば済むので、
安心して忘れましょう。
こういう感じでトップダウン的に作っていけば混乱せずにロジックを作れるかと思います。
慣れていけば先回りして細かいところから作れるようになります。
投稿2015/08/12 03:28
総合スコア13521
回答有難うございます。
仰るとおり、いっぺんに考えようとしているのかもしれません。
一つ一つ潰していくのが定石だというのに、Aについて処理中にCのことを触ったりしてしまうことがあります。
ただ、いっぺんに考える、というよりどれを考えていいか分からなくなる、という考える以前の話の状態になることが多いです。
0
苦手意識を抱いてしまうと、「自分が持っている強み」にも自信が持てず実力を発揮出来なくなります。
私は知識なし、技術なし、経験なしから･･･
とおっしゃっていますが、スタートは皆同じです。それに
私は完全なる文系脳です。
と言うのも、決して弱点ではありません。
文系脳の優秀な開発者はたくさんいらっしゃいますので、考え方次第では自分の「強み」に出来ます。
そもそも、要望を出すのも使うのもお客様ですが、その多くが文系脳の方なので、同じ目線で考えられることは、むしろメリットです。
さて本題ですが･･･
おおまかな処理を日本語で書くことはできます。
に問題の本質が示されていると感じました。
問題解決の「スタート」としては正しいです。が、しかし、そこからいきなりプログラミング言語で『実装』をしようとしていませんか？
それは無謀であるばかりか求められている事でもありません。
また、示された仕様を機械的にプログラムに置き換えても良いシステムになるとは限りません。
さらに、もしそれで事足りるならプログラマーなんか不要です。
優秀なプログラマーとは、以下の作業（思いつくまま列挙）を素早く正確に出来る人ですが
- 与えられた仕様を正確に把握する
- 与えられたら仕様に漏れや矛盾がないか検証する
- 仕様が不十分なら修正案を立案する
- 仕様を満たす効率の良い処理方式を考える
- 実装＆テスト＆メンテナンスがし易いモジュール分割を考える
- テストの方法やテストケースを考える
（ここでようやく）
- プログラムを実装する
- プログラムが仕様通りか検証する
これら複雑な作業を、もし仕様を眺めただけで出来てしまうようであれば、それは天才（神の領域に近い）であり、世界に数人もいるかどうかです。
通常は「仕様」←→「プログラム」を何度も行ったり来たりしながら完成度を高めて行きます。
偉大な先人たちは、この難しい作業を早く正確な行うための道具や方法をたくさん開発して下さっている訳すが、プログラミングに長けている人たちは、大抵、その中から適切な道具を選び使いこなすことに「慣れている」に過ぎません。
先輩方が「慣れだよ慣れ」や「経験しかない」などとおっしゃるのも、実はこの事をおっしゃっているのだと思います。
難しい問題を正確に理解し、漏れなく考え、仕様通りである事を検証するには、「日本語」という、とりわけ曖昧な道具だけでは到底太刀打ち出来ません！
スポーツの世界では「正しいフォーム」による「素振り」の繰り返しが重要なのと同様に、プログラミングの世界でも、「適切な道具」の「正しい使い方」を繰り返し練習しないと、何年経っても慣れることはできません。
『適切な道具を使いこなすこと』に関し、誤解を恐れず砕けた表現を用いれば
0. 細かく分けて考える
0. 図に描いて整理する
0. 漏れを見つけ出す手法を活用する
0. 車輪の再発明はしない
0. 面倒くさがり屋になる
ということです。
参考書を紹介して欲しいとの事ですが、実は、膨大な量の関連書籍から今の自分に合った数冊を選ぶというのは、それほど簡単な事ではありません。
一方、ちょっとググってみれば、Web上に掲載されている平易な解説を幾つも見つけることができます。
ですから、まずはそれらの解説にザッと目を通し、ふと目に留まった言葉や気に掛かったキーワードを２つ３つ書き留めて、そこから学び始めてみてはいかがでしょうか？
そうすれば参考書探しも失敗が少なくなります。
最後に、参考になりそうな解説ページへのリンクを張っておきます。
- 分析的に考えるための道具は「ロジカルシンキング」です。
新社会人のためのロジカルシンキング（論理的思考力）を鍛える訓練方法
- 図解のテクニックはあらゆる工程で役に立ちます。
- 漏れや勘違いを防ぐために、テスト技法の基礎を早い段階で身に付けましょう。
- こんな時はどうすれば良いか、という「定石」は、しっかり覚えてちゃっかり使っちゃいましょう、ということです。
アルゴリズムやデザインパターンなどが当てはまります。
初中級エンジニアが【アルゴリズムを優しく学べる】本とサイト16選
サルでもわかる 逆引きデザインパターン
（注意）決して覚える必要はありません。
覚える事よりもむしろ、こんな時はこんなのが使えそうだなぁ〜、とか、
こんなの無かったっけ？と、気づいたり思い出したりできる事こそ重要です。
- 面倒くさがるのは悪い事ではありません。自動化できる事はツール類の便利機能に任せ、自分は考える事に専念しましょう。
利用すると生産性が格段に向上する厳選Eclipseショートカット集
（補足）ショートカットの活用は、単に操作が早いという以上に、思考を中断させない
という重要な意味合いがあります！
以上、つれづれなるままに書きましたが、いくらかでもご参考になれば幸いです。
---[追記 ]---
ichamさんの回答に少しコメントしましたが･･･
「文系脳」とか「理系脳」というのは何らかの『能力』の違いを指している訳では無く、問題解決のアプローチの仕方の違い、言い換えると考え方の『癖』です。
なので、身に着けたい『癖』があれば練習すればよろしい。
と言うわけで、もしnatsu_xivさんがWBSに不慣れなら、先ずはこのレベルからどうぞ。
WBSの作り方
投稿2015/08/12 16:26
編集2015/08/14 04:38
総合スコア5936
回答ありがとうございます。
仕様の把握が具体的に確実にできていないのだと思います。
定石がほぼ私の中に無い状態なのでどう動かせばいいか分からないということが多いです。
数々のサイト等のご紹介ありがとうございます。是非参考にさせていただこうと思います。
0
私はあなたと正反対、完全な理系脳＆新人のころから「抜群にセンスがいい」と言われていました（自慢してごめんなさい）
なので、参考にはならないかもしれませんが私が考えるときの感じを書いてみます。
＞ロジックが組めないと言っても、おおまかな処理を日本語で書くことはできます。
ロジック考える時、私の頭の中に文章は出てきません。形が出てきます。
ファイル比較の例で考えてみます。
頭の中に雲みたいな塊をいくつか作ります。
「新」はピンク、「旧」は水色にしてみましょう。
雲の中に●とか▲とか入れてみます。
こっちのピンクとあっちの水色は同じの入っているから、ひもで繋げて「正」のバッチつけて。
”ひもで繋げる”のところをもうちょっと具体的にしてみよう。
みたいな感じです。
頭の中だけでイメージつかめないときは、紙に書いてみます。
1枚の紙に大きな丸２つ描いて、かたっぽが「新」、もう１つが「旧」
丸の中に●や▲描いて…
文章で考えるのと形（絵）で考えるのは、感覚的にかなり違ってくると思います。
最初から形を考えるのが大変なら、文章にしたものを絵にしてみたらどうでしょう？
気が向いたら試してみてください。
あなたが真面目な人で真剣に悩んでいるのが分かるので、皆さん解答して応援してくれているんですね。
投稿2015/08/14 03:04
総合スコア229
0
ペア・プログラミングできると良さそうな気がします。
比較的簡単なお題を持ってきて、
私ならこう書く、あなたならこう書く、その違いは何だ、
っていうのを積み重ねていけばメキメキ上達しそうな気がします。
投稿2015/08/14 02:15
退会済みユーザー
総合スコア0
0
僕も基本情報処理技術者試験をまず受けてみることをおすすめします。
というのも、例えば論理を整理するやり方を学ぶ機会ってあまりなかったと思います。ド・モルガンの法則とか、ベン図とか、真理値表とかご存知ですか？僕は情報系の学科出身ですが、この辺りの話を知っているのと知っていないのとでまず地力に差があります。なぜなら、例えば、これらを知っていれば、複雑なif文をこれらの技法を使って整理できるからです。
基本情報処理技術者試験やソフトウェア開発技術者試験は、本当にこの業界にたずさわるのなら知っておきたい知識をざっくりと知る事ができます。Javaとかの認定試験よりもです。どうぞ前向きに検討してみてください。
投稿2015/08/14 00:05
退会済みユーザー
総合スコア0
0
頭だけで考えていませんか？
まずは、どんな処理が必要か、どんな処理の流れになるか
メモ程度でも良いですし、フローチャートまでやってもいいですが
紙に書いてみることをオススメします。
投稿2015/08/12 08:02
総合スコア559
回答有難うございます。
頭だけで考えるのは無理なので紙などに書き出してはいますが、それ以前に、そもそもこの処理を実現するためにはどうすればいいんだ？？という状態でメモすらも書けない状態になるということが多いです。
コードで実現する前の整理として書き出すので、その時に「どうすればいいんだ？」と考えるから纏まらないような気がします。
紙に書き出すフェーズ
１．おおまかに全体像（処理の流れだけ）を考える。
２．処理の細部を文字ベースで考える。
ここまでコードの事は一切考えない。
文系の方が、ここまでの物語的なストーリ展開の考え方は優れていると思います。
コーディングするフェーズ
３．コードを書き始めたら、その処理をどう実装するかを考える。ある程度の内容であればネットで情報は溢れていますし、技術本を持っていれば、それを見るのも良いと思います。
先輩方も言われてますが、経験が糧になりますので、なるべく多くのコードを書くこと！
分からないのならコードを書いて試す、ダメなら書き直す。スクラップ & ビルドを何度も繰り返すと良いと思います。
1回で100%なコードを書くことはほぼないです。
とりあえず作って動かす、ダメなところを直す、わーいできた！
あれ、コードがぐちゃぐちゃだ。書き直す。
こんな事を繰り返して、上手くなっていくものだと思いますよ？
ichamさんの仰る通りです。
「どうすればいいんだ？」というのは、いわばゴールであり、最初からゴールが見えている様な単純な問題なら、わざわざnatsu_xivさんが給料をもらって解くまでもないのです。
プログラミングは、「～したい」という要求（＝仕様、抽象的）を、コンピュータの理解できる命令（＝具体的で曖昧さゼロ）の組み合わせに置き換える作業なので、やり方は人それぞれですが、与えられたら仕様を単純なタスクの組み合わせに変換する為の『分解』作業が不可欠です。
天才肌の人は殆ど頭の中だけで出来るかもしれないですが、凡人でも適切な道具を使い正しい手順に従えば、大抵の問題は解決出来ます。
もし『分解』することに不慣れなら、
WBSを書く練習をする事を強くお勧めします。
ぜひ、プログラミングとは無関係の「ごく普通の活動」についてWBSを書いてみてください。
迷わず出来るような作業は、改めてWBSを書くまでもなく（慣れているので）作業を自然と細かなタスクに分解し適切な順序で実行出来ている筈です。
上手くタスクに分解出来ない時は、分解できる程には問題を理解できていない証拠なので、もう一段、問題を分割します。
恐らくこの練習が、今のnatsu_xivさんには一番役立つのではないかと思います。
0
ベストアンサー
質問者様が公開してもよろしいならば、サンプルのコードが見たいですね。
もし仕事のコードがさしつかえあるなら、家で練習で書いたコードとか。
細かい手順が頭の中がごちゃごちゃになって分からなくなってしまいます。
分からなくなったら、問題を分解して各個撃破するのが、プログラミングの常套手段です。
とくに長くて複雑なコードを、関数やオブジェクトに適切に切り分けることは、
非常に重要だと思います。あとは変数や関数の命名やコードの可読性でしょうか。
ロジックを時間をかけず考えられるようになるにはどのような訓練をしたらいいのでしょうか。
それには、if文とfor文とか、クラスとメソッドとか、
プログラムの構造で柱になる部分から考えていきます。
コードを書くとどうしても細かい文法や処理に意識が向きがちであれば、
フローチャートやUMLなどで、まず図解をしてみるのも良いかもしれません。
そんな業務で毎回図解をする時間などない、と思われるかもしれませんが、
慣れてくれば図解をしなくてもイメージが湧きます。慣れるまでの練習です。
これを読んでおくと役に立つ、というような書籍等ありますでしょうか。
アルゴリズムの本は一冊読んでおきたいです。
即効性なら各言語の逆引き辞典とかですが、基礎力を付けるならアルゴリズム本が有効です。
（私はこれらの本のC言語版で学びましたが、質問者様はJavaを学んでおられるので、Java版を紹介しました）
Amazon.co.jp： 定本Javaプログラマのためのアルゴリズムとデータ構造
Amazon.co.jp： 明解 Javaによるアルゴリズムとデータ構造
投稿2015/08/11 17:32
総合スコア5592
回答有難うございます。
分からなくなったら問題を分解して…というのは試みるのですが、私がロジックが分からない、という場合はそもそもどこから考えるべきなのか、とパニックになってしまうのです。
今実現したいことはA。ならばまずBを考えなければならない。…いや、DもAの段階で必要…じゃあDを先にしないと実現しない？
のような感じですかね…
＞そもそもどこから考えるべきなのか
慣れるまではトップダウンとボトムアップと両方から攻めて、
その中間で組み合わせを試行錯誤するのが良いと思います。
慣れてる人はトップかボトムか一方からサーッと作れますが、
練習だと思って何度も書き直すことを嫌がらないでください。
トップからは文章や図解やアルゴリズムで問題を分解していき、
ボトムからは仕様の把握や逆引き本で手段をそろえていき、
中間部（「まずBを」「Dを先にしないと」みたいなこと）は、
プロトタイプ（簡単なサンプルコード）で実際に書いてみます。
このとき、関数やオブジェクトに切り分けておくと、
最初に書く量はほんの少し増えますが、
組み合わせや順番を試行錯誤しやすくなります。
0
プログラミング歴２年で、その実力なのは、まあ普通だと思います。
あなたの上司は即戦力を期待していますので、あなたはその期待を裏切っていることになりますが、現段階ではあなた自身に非があるとは思いません。
あなたが、完全なる文系脳であることは、それほど大きなデメリットではありません。
そもそもプログラミング言語は言語であり、ソースコードは文章なので、文系の能力は必要です。
ただし、理数系の能力や発想力がないと、ある種の問題が解決できなくなりますが、コードが書けなくなるほど致命的なものではありません。
プログラミングとは、これから作ろうとしているソフトウエアの内容を、それを全く知らない人を相手に、具体的に詳細に漏れなく説明することです。
この説明を日本語で行う代わりに、プログラミング言語で行うと、それがそのままソースコードになります。
人間は相手の思いを察することができるため、非常に少ない言葉だけでも説明できてしまいます。
しかし、コンピューターは人間の思いを察することができないため、具体的に詳細に漏れなく説明することが必要になります。
細かい処理ロジックが書けないなら、その処理内容を端折ったりせず、具体的に詳細に漏れなく説明することに集中してください。
あと、ソースコードを文章として見たとき、その内容は大きく「定義」と「手続き」に分かれます。
定義は、「◯◯は△△である。」という文章です。
手続きは、「◯◯を△△する。」という文章です。
処理内容を説明する際は、この２つの文章を組み合わせて行うことを考えてください。
投稿2015/08/11 17:01
総合スコア2183
回答有難うございます。
具体的に詳細にもれなく説明する、という点ですが、そもそも自分の頭のなかにやるべき処理が漏れている、というか「知らない」ことが多いです。先輩等のコードや説明を聞いて初めて「そうすればいいのか」となります。
今回はその考え方部分を先輩のもご教授頂きたかったのですが、仕様がわかってないね厳しいねで終わって引き取られてしまいました。
それは、細かい処理ロジックが組めないのとは、少し違う話のような気がします。
知らないことは、いくら考えても知らないままなので、覚えるしかありません。
私の話は、特定のプログラミング言語や開発環境に依存しないものですが、JavaやVBAなどのライブラリやAPIなどは、それぞれの言語や開発環境ごとに覚えなければならないものなので、ひたすら勉強するしかないですね。
0
基本的にプログラムは上から下
ループと条件分岐ですよ
後は、個々の関数や命令を組み合わせるだけです
この基本を忘れるとラーメンソースが出来たり、仕様が分からなくなると思います
投稿2015/08/18 13:25
総合スコア44
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2015/08/12 23:08
退会済みユーザー
2015/08/12 23:56